1. Field of the Invention
This invention is related to the field of processors and, more particularly, to exception handling within processors.
2. Description of the Related Art
Microprocessor designers often design their products in accordance with the x86 microprocessor architecture in order to take advantage of its widespread acceptance in the computer industry. Because the x86 microprocessor architecture is pervasive, many computer programs are written in accordance with the architecture. X86 compatible microprocessors may execute these computer programs, thereby becoming more attractive to computer system designers who desire x86-capable computer systems. Such computer systems are often well received within the industry due to the wide range of available computer programs.
The x86 microprocessor architecture specifies a variable length instruction set (i.e. an instruction set in which various instructions employ differing numbers of bytes to specify that instruction). For example, the 80386 and later versions of x86 microprocessors employ between 1 and 15 bytes to specify a particular instruction. Instructions have an opcode, which may be 1-2 bytes, and additional bytes may be added to specify addressing modes, operands, and additional details regarding the instruction to be executed. Certain instructions within the x86 instruction set are quite complex, specifying multiple operations to be performed. For example, the PUSHA instruction specifies that each of the x86 registers be pushed onto a stack defined by the value in the ESP register. The corresponding operations are a store operation for each register, and decrements of the ESP register between each store operation to generate the address for the next store operation.
Often, complex instructions are classified as MROM instructions. MROM instructions are transmitted to a microcode unit within the microprocessor, which decodes the complex MROM instruction and produces two or more simpler microcode instructions for execution by the microprocessor. The simpler microcode instructions corresponding to the MROM instruction are typically stored in a read-only memory (ROM) within the microcode unit. The microcode unit determines an address within the ROM at which the microcode instructions are stored, and transfers the microcode instructions out of the ROM beginning at that address. Multiple clock cycles may be used to transfer the entire set of instructions within the ROM that correspond to the MROM instruction. Different instructions may require differing numbers of microcode instructions to effectuate their corresponding functions. Additionally, the number of microcode instructions corresponding to a particular MROM instruction may vary according to the addressing mode of the instruction, the operand values, and/or the options included with the instruction. The microcode unit issues the microcode instructions into the instruction processing pipeline of the microprocessor. The microcode instructions are thereafter executed in a similar fashion to other instructions. It is noted that the microcode instructions may be instructions defined within the instruction set, or may be custom instructions defined for the particular microprocessor. Of course the use of microcode is not limited to x86 microprocessors. Many different types of microprocessors employ microcode units.
Conversely, less complex instructions are decoded by hardware decode units within the microprocessor, without intervention by the microcode unit. The terms xe2x80x9cdirectly-decoded instructionxe2x80x9d and xe2x80x9cfastpath instructionxe2x80x9d will be used herein to refer to instructions which are decoded and executed by the microprocessor without the aid of a microcode unit. As opposed to MROM instructions which are reduced to simpler instructions which may be handled by the microprocessor, directly-decoded instructions are decoded and executed via hardware decode and functional units included within the microprocessor.
Another use of microcode is in exception handling. An exception may occur in a processor when the processor is unable to complete an instruction. For example, an exception may be generated from a divide instruction when the divisor is zero. Also, an exception may be generated if an invalid opcode is detected by the execution unit. Other type of exceptions may occur from memory operations. The term xe2x80x9cmemory operationxe2x80x9d is an operation which specifies a transfer of data between a processor and memory (although the transfer may be accomplished in cache). Load memory operations specify a transfer of data from memory to the processor, and store memory operations specify a transfer of data from the processor to memory. Load memory operations may be referred to herein more succinctly as xe2x80x9cloadsxe2x80x9d, and similarly store memory operations may be referred to as xe2x80x9cstoresxe2x80x9d. Memory operations may be implicit within an instruction which directly accesses a memory operand to perform its defined function (e.g. arithmetic, logic, etc.), or may be an explicit instruction which performs the data transfer only, depending upon the instruction set employed by the processor. Generally, memory operations specify the affected memory location via an address generated from one or more operands of the memory operation. This address will be referred to herein in as a xe2x80x9cdata addressxe2x80x9d generally, or a load address (when the corresponding memory operation is a load) or a store address (when the corresponding memory operation is a store). On the other hand, addresses which locate the instructions themselves within memory are referred to as xe2x80x9cinstruction addressesxe2x80x9d.
Exceptions resulting from memory operations may be referred to as load/store exceptions. An example of such an exception is a page fault which occurs if when translating a linear address to a physical address, the processor determines that the page containing the operand is not present in physical memory. Typically, when an exception occurs, control may be transferred to a microcode routine to handle the exception. For example, for a page fault the exception handling routine may perform certain architecturally required tasks and then pass control to software (e.g., the operating system) to load the missing page into memory. Execution may then return to the instruction from which the page fault occurred.
An exception, such as a load/store exception, may occur during execution of an MROM instruction. For example, during: the execution of the microcode routine that implements an MROM instruction, a page fault may occur. The exception will cause the processor to be redirected to the exception handler (which is typically a microcode routine). Typically, the microcode fault handler must initially perform certain clean-up operations before an exception can be handled. For example, the MROM instruction routine that was interrupted by the exception may have left the processor state in a partially completed state. It may be necessary for the exception handler to xe2x80x9cclean upxe2x80x9d the processor state before the exception handling can continue. Just what sort of clean up is required depends upon the context in which the exception occurred. Depending on what MROM routine was interrupted or at what point a routine was interrupted, different clean-up may be required. Thus, the exception handler must determine the context in which the exception occurred.
Turning now to FIG. 1, a prior art example of how an exception handler may determine the context in which an exception occurred. There exist some number of microcode routines (labeled A through D in the example of FIG. 1). Each of these routines alter macro-architectural state (visible to the programmer) or micro-architectural state (internal to the processor). Further, each of these routines can be prematurely terminated by an exception or interrupt before they complete. Exceptions/Interrupts transfer control to the microcode""s generic exception processing routine (labeled xe2x80x98Xxe2x80x99). The exception processing microcode implements the architecturally required elements of exception handling (e.g. building a stack frame, transferring control to find the software handler for this exception). But before doing that, it is usually necessary to correct or fixup some of the previously mentioned macro- or micro-architectural state that was left in a partially completed state. This fixup may include undoing some or all of the state changes of the interrupted routine, altering CPU state to reflect the progress of the interrupted routine, etc. The precise fixup action is specific to which routine was interrupted and possibly where in the routine the exception or interrupt occurred. Thus many different fixup routines may need to be included within the generic exception processing routine. In the example of FIG. 1, in order for the microcode generic exception processing routine (xe2x80x98Xxe2x80x99) to run the correct fixup routine, microcode maintains a flag (labeled FA through FD) for each original routine. This flag must be set before any routine can take an interrupt and just as importantly, they must be cleared if no exceptions take place. These flags are then tested in the exception handler to determine which routine was interrupted and hence which fixup routine needs to be run. Maintaining and testing these flags requires additional microcode space and complexity. Thus, it may be desirable to improve how context-related clean-up is performed for exceptions in order to reduce the complexity and/or improve the efficiency of generic microcode exception processing routines.
One prior art processor has attempted to improve fault handling by providing registers in the processor""s microcode unit that can be used to specify the address of an alternate fault handler and a default fault handler in the microcode. This mechanism employs a first register to specify the alternate fault handler microcode ROM address, a second register to specify the default fault: handler address, a multiplexor to provide the contents of one of the registers to the microcode engine, and a third register to specify which of the first two registers should be selected by the multiplexor. The first, second, and third registers are special registers that are not part of the processor""s regular register address space. Accordingly, special microcode instructions are provided whose sole purpose is to program these registers. A microcode routine may use one of these special microcode instructions to write to these special registers to enable an alternate fault handler. If an exception occurs after the alternate fault handler is enabled, the specified alternate fault handler may perform any necessary clean-up operations before jumping to the regular (default) fault handler. When it is no longer desired to have the alternate fault handler enabled, such as when exiting a microcode routine, the special microcode instructions must be used to write to these special registers to disable the alternate fault handler and enable the default fault handler. Thus, this mechanism is somewhat complex and cumbersome. Multiple registers and other hardware is required for the mechanism. Also, special microcode instructions must be added to the microcode instruction set in order to program the registers. Additionally, multiple register writes are required to enable and disable alternate fault handlers. Thus, an improved alternate fault handler mechanism is desirable.
Instead of executing one generic exception handler, when an exception is received, such as a load/store exception, alternate fault handler routines may be executed depending upon the context in which the exception is received. By executing an alternate fault handler from microcode based on the context of the exception, the microcode may restore state, change the fault type, or change error codes before jumping to the generic fault handler if necessary. The use of alternate fault handlers may simplify both the microcode and hardware by eliminating or reducing the need to determine the context in which an exception occurred.
In one embodiment a reorder buffer maintains a load/store (LS) fault address register (LSFAR). When the processor""s load/store unit reports most LS exceptions, the reorder buffer redirects the microcode unit of the processor to execute a fault handler indicated by an address stored in the LSFAR. The LSFAR may be mapped into the register space of the processor. It may be written by a microcode routine with the address of a specific fault handler at the beginning of a microcode routine or at any time during a microcode routine. As the reorder buffer retires instructions it checks for writes to the LSFAR. If one exists, the reorder buffer loads the result data of that write into the LSFAR. In a preferred embodiment the reorder buffer retires instructions in program order and the LSFAR is not updated speculatively.
Once a value is written into the LSFAR the fault handler specified by the value is in effect until the LSFAR is updated with a new value. Upon exiting each microcode routine, LSFAR is returned to a default value which may point to the generic fault handler in microcode. LSFAR may also be returned to the default value if the processor receives a reset. However, an abort in which speculative instructions are cancelled in the reorder buffer does not return LSFAR to the default value. Instead, the current LSFAR value is maintained.
Inside each alternate fault handler, microcode exists to do any required clean-up, restoring of state, or changing of fault codes as required for precise exception handling according to the architectural definition of the processor. After performing its fix-ups the alternate fault handler may jump directly to the default exception handler or some other exception entry point.
In one embodiment a processor includes a microcode unit having a microcode memory configured to store microcode routines for implementing microcoded instructions and microcode routines for exception handling. The processor also includes one or more execution units configured to execute the microcode routines and exception logic configured to indicate if an exception occurs during execution of one of the microcode routines. A register, such as the LSFAR, is configured to store a value indicating the location of an exception handling routine in the microcode memory. If an exception occurs during execution of one of the microcode routines, the exception handling routine indicated by that value is executed. The register value may be changed for different ones of the microcode routines to indicate different exception handling routines.
Thus, an alternate fault handler method may include writing a register in the processor with a first value indicating a specific exception handling routine. If an exception is generated while the register contains the first value then the exception handling routine indicated by that value is executed in response to the exception. As the processor context changes, such as during execution of a different microcode routine or a different portion of a microcode routine, the register may be written with a different value indicating a different exception handling routine such that if an exception is generated while the different exception handling routine is indicated by the register then that exception handling routine will be executed in response to an exception. The method includes automatically restoring the register to indicate a default exception handling routine upon exiting a microcode routine.
In one embodiment, a processor may include a register configured to store different values where each different value indicates the location of a different condition handling routine. The processor may also include one or more execution units configured to execute program instructions and logic configured to receive a condition during execution of the program instructions. The logic may cause execution of the program instructions to be interrupted and may cause the condition handling routine indicated by the value stored in the register to be executed to handle a condition that is received while that particular value is stored in the register. The condition may be an exception or an interrupt, for example. The value stored in the register is chosen so that if the condition occurs the value will indicate one of the condition handling routines specific to the context in which the condition occurred.
During execution of a microcode routine an exception handler address register may be loaded with an address of an exception handling routine. If an exception is received after loading the address into the exception handler address register, in response to the exception, a microcode unit of the processor may be redirected to issue microcode instructions for executing the exception handling routine located in microcode memory at a microcode memory address as indicated by the address in the exception handler address register. Different addresses may be loaded in the exception handler address register during the execution of the microcode routine or during execution of other microcode routines. The addresses loaded indicate the microcode address of an exception handling routine stored in the microcode memory specific to the processor context while that address is stored in the exception handler address register. The processor context may refer to the particular microcode routine or portion of a particular microcode routine for which a particular address is loaded in the exception handler address register. Upon exiting microcode routines, the exception handler address register may be automatically restored to indicate the address of a genenric exception handling routine in the microcode memory.